Summary

Reorder HttpStatus.CONTENT_TOO_LARGE to appear before its deprecated counterpart PAYLOAD_TOO_LARGE to align with existing ordering conventions.

Details

In previous versions, HttpStatus.resolve (or valueOf) always returned non-deprecated HTTP status for given code. This was ensured implicitly, by placing non-deprecated enum entries before their respective deprecations. This was not ensured for 413 Content Too Large.

You can see this lower in this enum - 422 Unprocessable Content is before its deprecated 422 Unprocessable Entity and in previous versions, 414 URI Too Long was before its deprecated 414 Request-URI Too Long.

Even JavaDoc (from 6.2.x) for 414 used to explitly state, that non-deprecated one will be returned:

	/**
	 * {@code 414 URI Too Long}.
	 * @since 4.1
	 * @see <a href="https://tools.ietf.org/html/rfc7231#section-6.5.12">
	 *     HTTP/1.1: Semantics and Content, section 6.5.12</a>
	 */
	URI_TOO_LONG(414, Series.CLIENT_ERROR, "URI Too Long"),
	/**
	 * {@code 414 Request-URI Too Long}.
	 * @see <a href="https://tools.ietf.org/html/rfc2616#section-10.4.15">HTTP/1.1, section 10.4.15</a>
	 * @deprecated in favor of {@link #URI_TOO_LONG} which will be returned from {@code HttpStatus.valueOf(414)}
	 */
	@Deprecated
	REQUEST_URI_TOO_LONG(414, Series.CLIENT_ERROR, "Request-URI Too Long"),

Therefore I believe that CONTENT_TOO_LARGE enum entry should be moved before PAYLOAD_TOO_LARGE to match that.